In circa December 2018, a former colleague explained what he saw as the difference between frontend development and backend development thusly. He leaned back in his chair, smiled as though recalling the joyful face of a loved one, and lifted his hand as to emulate the delicate handling of a much-anticipated glass of good wine (alas, the company policy forbade an authentic recreation, and having only a crumpled bottle of Lucozade available he opted instead to mime); and he declared that the backend developer will ponder, and take a sip of wine (elegantly so mimed), and then, perhaps, write a line of code or two. He reached forward with his other hand and mimicked the chording of some keyboard, and then leant once more to take another sip, declaring that all would be well and the money would flow.
"Whereas a frontend developer..." he continued, replacing himself and setting down his imaginary glass, dismissing both it and his calm countenance with a rupturing crash as he slammed both arms on the table. "Quick!" he cried, both arms now swinging, papers that still had purpose later in the day flying for safety, "It's been seventy-two seconds and we haven't rewritten the framework!" His body convulsed, the table threatened collapse. "We need to give a keynote! We need to deploy right now!"
Before even six months had passed following this unforgettable moment of lunchtime philosophy, React had announced the release "with hooks", Vue had adopted a brand new syntax, and Angular had introduced Ivy. Only a few months before, Microsoft had announced the complete rebuild of Edge, HTML5 was retired, Typescript's type system had ballooned with its 3.0 release, and WCAG 2.1 was published. This buck-wild pace of change managed to persist for the next six years as both the web and the tools to control it were rushed, ready or not, into maturity; a new generation of barely conscious developers were armed with considerably more powerful tools with which they would commit far more dangerous crimes.
My journey through the swamp of web development started much earlier however; I built my first webpage as a gormless 13 year old in school with the help of Adobe Dreamweaver 1000 years ago (2010ish). I won't speak for Dreamweaver today (to be frank I'm astonished it still lives) but whatever version coughed into life back then was not fit for purpose as a web development tool; it invited me to drag boxes around a page of fixed size, and position them absolutely, and then see the results that worked well on specifically my screen size and no other. Thankfully, the switched on lad next to me said we could just craft a page by hand in a far superior tool: Windows Notepad. I wrote some template and some style and then saw the results by opening the html file in a browser, no server needed. It was an ugly, hopeless thing, though less so in IE 8 which didn't support fancy new rules like text-shadow and border-radius; I recall even then, innocent to much of the world's evil, being baffled by how poorly IE complied with standards.
I was too late to be a part of the exquisite nightmare of tables as layout managers, but I was in time to get stuck in with the terrifying css rule 'float'; I was in time to partake in the universal moan about the difficulty of vertically centring content; and to rhapsodise about the beauty of flex layouts when they arrived; and to bitch like a child when it turned out that everything had to be polyfilled and vendor-prefixed and checked across seven browsers because of wild variance in standards compliance. In all that time, I was picking up some terrible habits and lessons: that web dev was a clown's funhouse of trap doors and misdirects; that I too was now a clown performing tricks and sleights of hand to make things work; that an enormous template full of bespoke nonsense to be manipulated by random scripts and sparsely supported css was both necessary and good. I became very good at building sites from scratch, doing all styling and scripting myself, because I was a hobbyist developer primarily using the experience to create art rather than tools of use. I knew how to do responsive design, say, but none of my creations were, in any meaningful sense of the word, accessible.
My first industry role gleefully threw me into a raging storm of progress that rendered my skillset quaint at best, comically naïve at worst; now was the era of single-page applications and opinionated frameworks and typed javascripts. Power users needed power tools to power through mountains of data for whatever reason justified continued employment. Forms and buttons and headers were now the remit of chunky design libraries; a list of items was now a third party concern to be paginated from a backend and virtualised in the frontend; URLs were now as putty to seal away any helpful functionality a browser's 'back' button might once have provided. None of what we built met any accessibility standard: these were internal tools to be run on monstrous machines powering enormous monitors for a tiny set of customers; but even for that small set we'd fallen short. I found out from a colleague how poorly the apps handled browsers' 'font size' setting, which allowed scaling fonts independently of pages as a whole. The setting butchered all of our tools almost artfully: text was warped, clipped, overlapping, or missing altogether; horizontal scroll bars decorated the page as would fairy lights a Christmas tree; a company logo now claimed a quarter of the viewport. I felt terrible for the guy, who was now in the habit of turning the setting off before loading the tool, straining through a task, and then re-enabling it afterwards, assuming his accessibility needs would never be prioritised against other work. Gratefully I was given some time to investigate it, but there was little to be done: our codebases, well-kept codebases, were enormous communes of carefully integrated third party tools and sprawling templates and custom functionalities; each part was both a crucial contribution to the whole and yet a unnecessary interruption on the standard functions of the browser. Need the virtualised list demand a fixed height for each entry within it? Must the design system enforce a particular font size for buttons? Why is every scroll action hijacked? Why is it all so complicated?
Today, I work with a web app that is public-facing — specifically EU-facing, where non-compliance with WCAG 2.1 can see a company fined. The web app is an Angular e-commerce website; it should, relative to my previous banes at least, be simple. It is not. It is unbelievably noisy. A bespoke design system turns even simple buttons into three layers of wrapping divs and other Angular boilerplate. A fantastically realised concoction of scroll listeners turns any visible headers or filters into a living and breathing characters that dance about the page, and respond to stimuli, and become needy if left unprompted too long. Entirely bespoke experiences visible only to those with particular screen widths evoke the spirit of adventure games that would hide secrets in seldom-searched corners as a thank-you to those dedicated enough to seek them. This accumulated debris whispers to me; it yarns wistfully of the distrust in browser functionality that begat it, of generations of carousel libraries standing firm against the evil horizontal scroll bar, of valiant and hopeless abstractions over now- and long-standardised APIs, of a million little tricks to squeeze out some extra loading speed for a hero image the customer neither wanted nor needed to see.
By now I had learned the lesson: a substantial amount of accessibility compliance comes naturally from the tools of our trade. Our mission is to show restraint before the eternal urge to complicate; to reject the assumptions we so easily make that users so easily break; to appreciate those clever designers who managed to make a system where what's good and what's easy overlap considerably. Such equanimity doesn't come naturally to me, so I'm practicing it here with as unbusy a site as still brings me joy. I started with a previous project's bulky extant structure, and kept stripping back until I was innovating no more. The frontend development landscape and the chaos thereto can't hear me in here; here I can rest. I can acknowledge the incredible power now available to me, and decide that, maybe, my site will never need a carousel when a smaller list will do, and my site will never need a virtualised list when a paginated one will do, and my site will never need an enormous hero image when a small one will do. This doesn't mean the site's fully accessible (my eggbug was missing alt text until just now) but it's a start.